<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
  <HEAD>
    <TITLE>Ebtables (Ethernet Bridge Tables) Frequently Asked
    Questions</TITLE>
    <LINK rel="SHORTCUT ICON" href="">
    <LINK rel="STYLESHEET" type="text/css" href="ebtables.css">
    <META name="description" content=
    "Ethernet Bridge Tables Frequently Asked Questions">
    <META name="author" content="Bart De Schuymer and Nick Fedchik">
    <META name="keywords" content=
    "Linux, netfilter, firewall, bridge, brouter, ebtables, iptables">
    <META name="keywords" content=
    "FAQ, kernel, ebtables, br-nf, br-nf-bds, ethernet, nat, chains, rules, tables">
  </HEAD>
  <BODY>
    <DIV class="banner" align="center">
      <H1>Ebtables (Ethernet Bridge Tables) Frequently Asked Questions</H1>
    </DIV>
    <A name="top"></A>
    <P>Last modified: November 09, 2003</P>
    <H2>Questions</H2>
    <OL>
      <LI><A href="#quiz0">Intro</A></LI>
      <LI><A href="#quiz1">Installation</A></LI>
      <LI><A href="#quiz2">Usage</A></LI>
      <LI><A href="#quiz3">Problems</A></LI>
      <LI><A href="#quiz4">Other</A></LI>
    </OL>
    <H2>Answers</H2>
    <OL>
      <LI>
        <B><A name="quiz0">Intro</A></B> 
        <DL>
          <DT>What is ebtables?</DT>
          <DD>The ebtables project is the Linux 2.5.x (and above) Link Layer
          firewalling subsystem, a patch for 2.4.x is maintained too.
          It delivers for Linux the functionality of
          Ethernet frame filtering, all kinds of frame NAT (Network Address
          Translation) and frame matching. The ebtables infrastructure is
          a part of the standard Linux 2.5.x (and above) kernels.</DD>
          <DT>Why would I use it?</DT>
          <DD>To filter frames by MAC-address or frame type at
          Link Layer inside your Linux-based Ethernet bridge, to do
          some basic filtering of certain protocol headers, to
          make a Linux brouter.</DD>
        </DL>
        <A class=navbar href="#top">[Back to the top]</A>
        <HR>
      </LI>
      <LI>
        <B><A name="quiz1">Installation</A></B> 
        <DL>
          <DT>How do I install the kernel part?</DT>
          <DD>First step is to decide what kernel version to use. If you
          want to use a 2.5.x (or above) kernel, then just use the latest
          and greatest kernel version. You won't have to patch the kernel.
          </DD>
          <DD>If you want to use a 2.4.x kernel, then go to
          <A href="http://sourceforge.net/projects/ebtables/">Ethernet bridge
          tables</A> and download the latest patch from the <B>2.4-ebtables-brnf</B>
	  package. Apply the patch as follows (substitute "linux" for the appropriate directory):
          </DD>
<PRE>
# cp ebtables-brnf-3_vs_2.4.22.diff.gz /usr/src/linux
# cd /usr/src/linux
# gunzip ebtables-brnf-3_vs_2.4.22.diff.gz
# patch -p1 &lt; ebtables-brnf-3_vs_2.4.22.diff
</PRE>
          </DD>
          <DT>What is the "ebtables" package and how do I install it?</DT>
          <DD>
            The <B>ebtables</B> package contains the ebtables userspace
            tool. This ebtables binary is used to make filtering
            rules for the Linux-based Ethernet bridge. All traffic entering
            or leaving on a bridge port will be seen by the rules. The ebtables usage is very
            similar to the iptables, so it should not be so hard. Of
            course, there is a man page supplied. Just gunzip and untar the
            package and read the INSTALL file.<BR>

<PRE>
# make
</PRE>
            Copy the ebtables binary, man page and protocol file to the correct
            directory (see the INSTALL file for options):
<PRE>
# make install
</PRE>
          </DD>
        </DL>
        <A class=navbar href="#top">[Back to the top]</A>
				<HR>
      </LI>
      <LI>
        <B><A name="quiz2">Usage</A></B>
        <DL>
          <DT>Can I filter on ARP packets in the Linux bridge box using
          ebtables?</DT>
          <DD>Yes, it's possible to filter on the ARP header, using ebtables.
          See the <A href="http://ebtables.sourceforge.net/ebtables-man.html">ebtables manual page</A> for
          details.</DD>
          <DT>Can I use ebtables with iptables? Are there any problems to
          use it together? How exactly is the packet/frame traversing order for ebtables/iptables?</DT>
          <DD>Yes, it's possible to use ebtables together with iptables, there are no incompatibility issues. Detailed
          info about ebtables/iptables interaction is explained at the
          <A href="http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html">
          "ebtables/iptables interaction on a Linux-based bridge"</A> page.</DD>
          <DT>Does ebtables keep count statistics?</DT>
          <DD>
            Yes, it's possible to view the match and byte count for every rule, using
<PRE>
# ebtables -L --Lc
</PRE>
          </DD>
          <DT>When using the option --Lc, what does the pcnt value represent?</DT>
          <DD>
          Normally, pcnt will represent the number of frames that matched this rule. However,
          if IP connection tracking is enabled, all fragmented IP packets will first be
          defragmented. Therefore, the pcnt value for IP packets will then represent the
          number of matched IP packets, not the number of matched frames containing IP fragments.
          In the BROUTING chain however, pcnt will always represent the number of matched frames, since
          the IP connection tracking is not done before this chain is traversed.
          </DD>
          <DT>What is this brouter stuff and when is it useful?</DT>
          <DD>
          The ebtables BROUTING chain gets traversed very early, namely right after a frame
          is received on a forwarding bridge port. If a rule's decision is to route the frame,
          the input device will remain the physical device of the bridge port and the bridge
          code won't touch the frame. The frame will be processed by the network stack. If the
          decision is to bridge the frame (the default behaviour), then the input device will
          become the bridge device on which the port is enslaved and the bridge code will decide
          what to do with the frame.</DD>
          <DT>So, what's the difference between the ebtables BROUTING and PREROUTING chains?</DT>
          <DD>The ebtables PREROUTING chain is only traversed when the bridge code is deciding what
          to do with the frame. So, if a BROUTING chain rule decided the frame should be routed, then
          the ebtables PREROUTING chain won't see it. See the
          <A href="http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html">
          "ebtables/iptables interaction on a Linux-based bridge"</A> page for the details.</DD>
          <DT>I'm using a 2.5.x or higher kernel and my iptables rules won't match on the bridge port
          devices, what's wrong?</DT>
          <DD>
          There is one difference between the br-nf behaviour in the 2.5.x or higher kernels and
          the 2.4.x patch. To get the br-nf code accepted into the standard 2.5.x kernels, we had to
          remove the code that automatically checked on the bridge port in the iptables port checking
          code (options -i and -o). Instead there is now an iptables match module, called 'physdev', that
          can be used to filter on the bridge ports. This match module has some extra options and
          is in the standard 2.6 kernels, the corresponding userspace module is available in the
          iptables userspace tool. See the iptables man pages and
<PRE>
# iptables -m physdev -h
</PRE>
          The kernel module has to be compiled in the kernel, the option 'physdev match support' will
          appear under the 'IP netfilter configuration' when the bridge is already enabled in the
          configuration.
</DD>
        <DT>I want to use the most recent ebtables code, even if it's not yet in an official release.
        How do I do this?</DT>
        <DD>
        The most recent code is available at the <A href="http://sourceforge.net/projects/ebtables">
        sourceforge ebtables</A> CVS repository. To get a copy of the repository, do the following:
<PRE>
# cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ebtables login
# cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ebtables co ebtables2
</PRE>
        The current userspace code is in the ebtables2/userspace/ebtables2 directory. To compile the
        CVS userspace tool you'll need to do the following:
<PRE>
# make KERNEL_INCLUDES=/usr/src/linux/include/
# make install
</PRE>
        Obviously you'll need to use the right kernel directory.</DD>
        <DD> Why is compiling the CVS different?
        Because the kernel include files are not maintained in the userspace directory of the CVS.
        When a new ebtables release is made, the kernel include files get copied in the tar file, so
        the standard installation knows where to get its kernel include files.</DD>
        <DD>The ebtables CVS tree has its own kernel tree with ebtables related files (for 2.4 and 2.6).
        The CVS directory (base_dir)/ebtables2/kernel/linux2.5/include/ can be used for compiling the userspace tool.
        </DD>
        <DD>New ebtables modules might not yet be in the standard kernel. The CVS directory
        (base_dir)/ebtables2/kernel/linux2.5/net/bridge/netfilter/ contains the not yet submitted modules. The modules
        that are already in the standard kernel are also in this directory and they are normally in sync with the latest
        kernel release.
        </DD>
        </DL>
        <BR>
         <A class=navbar href="#top">[Back to the top]</A>
      <HR>
      </LI>
      <LI>
        <B><A name="quiz3">Problems</A></B><BR>
        <DL>
          <DT>My bridging box seems to drop all IP packets, which is not what I want and I'm sure my
          ebtables rules don't drop them.</DT>
          <DD>Your iptables rules are probably dropping them then. By default, on a Linux bridging firewall all
          bridged IP packets are seen by iptables, so you should take that into account.</DD>
          <DT>This stuff isn't working on my 64-bit machine with a 32-bit userspace (like the Sparc64)</DT>
          <DD>As from ebtables v2.0.5, ebtables-brnf-2_vs_2.4.21.diff.gz and above 2.6.0-test1, it should work on a Sparc64.
          In case it doesn't, please notify the ebtables-devel mailing list. Making it work on a different 64/32 processor
          should be easy, but we'll wait for someone to come along who asks for this and who can consequently test the fix.</DD>
          <DT>I'm getting a message that looks like: ``br_netfilter: Argh!! : bad mac.raw pointer''</DT>
          <DD>We sometimes get reports about this message occurring. The bridge-nf code reports this message when a
          specific irregularity is observed, in technical terms: the mac.raw pointer of the sk_buff isn't set properly.
          The most likely cause of this is the network device driver. Since this only happens for a few persons, the
          only way to debug this is if those persons are willing to try patches. Up until now this has not been the case.<BR>
          The easiest solution is to try a different type of network card or a different device driver.
          </DD>
          <DT>I'm getting this message when doing IP DNAT: ``Performing cross-bridge DNAT requires IP
          forwarding to be enabled''</DT>
          <DD>First make sure IP forwarding is enabled:
<PRE>
# echo 1 > /proc/sys/net/ipv4/ip_forward
</PRE>
          If that's the case and the message doesn't go away, make sure your routing table has all necessary
          entries. For example, suppose we want to DNAT traffic on a bridge device that doesn't have an IP address to
          an IP address somewhere on the Internet.
<PRE>
eth0 = connection to Internet
br0 = eth1+eth2
br0 has no IP address
iptables -t nat -A PREROUTING -s 172.16.1.2 -d 172.16.1.4 -j DNAT --to-dest &lt;destination&gt;
route -A -net 172.16.1.0 netmask 255.255.255.0 dev br0
</PRE>
        172.16.1.2 is on the eth1 side, .4 on the eth2 side, the &lt;destination&gt; is somewhere on the Internet.
        Without the routing table entry (last line above), it is obvious that this DNAT wouldn't work (because the bridge/router
        wouldn't know where to send 172.16.1.xx traffic). It is possible that the mentioned
        error message gets printed on the screen or in your logs when this routing table entry is omitted.
        </DD>
        <DT>I'm trying to create a brouter that routes all IP traffic using the command "ebtables -t broute -A BROUTING -p IPv4 -j DROP", but it's not working...</DT>
        <DD>The DROP target in the BROUTING chain doesn't change the MAC destination to the bridge device, by default. You need
        to explicitly do this by using the redirect target:
<PRE>
ebtables -t broute -A BROUTING -p IPv4 -j redirect --redirect-target DROP
</PRE>
        </DD>
        </DL>
        <BR>
        <A class=navbar href="#top">[Back to the top]</A>
      </LI>
      <LI>
        <B><A name="quiz4">Other</A></B><BR>
        <DL>
          <DT>I'm not a Linux system's programmer, but I need a feature, which
          is not (yet) implemented in ebtables. What should I do?</DT>
          <DD>Subscribe to the <A href= "https://lists.sourceforge.net/lists/listinfo/ebtables-user">
          ebtables users mailing list</A>. Then post a short and clean description of
          your wanted feature to this mailing list.</DD>
          <DT>I'm a C programmer and I want to add an ebtables feature by
          myself. Where should I begin?</DT>
          <DD>Subscribe to the <A href=
          "https://lists.sourceforge.net/lists/listinfo/ebtables-devel">ebtables
          developers mail list</A>. Read the <A href=
          "http://ebtables.sourceforge.net/ebtables-hacking/ebtables-hacking-HOWTO.html">"Ebtables Hacking HOWTO"</A> and
          have a look at the already implemented modules. You will find that
          adding a module is not very hard. Additional information is available
          at the ebtables <A href="http://ebtables.sourceforge.net">
          homepage</A>.</DD>
        </DL>
        <BR>
        <A class=navbar href="#top">[Back to the top]</A>
      </LI>
    </OL>
    <HR>
  </BODY>
</HTML>
